解析OpenShift的存储规划

上一篇分享了：PaaS中OpenShift持久化存储的管理实践和 解密OpenShift内部通信网络

本篇继续分享OpenShift的存储规划

1

OpenShift 使用存储类型选择

选择合适的存储有助于最大限度地减少所有资源的存储使用。通过优化存储, 管理员帮助确保现有存储资源以高效的方式工作。在 OpenShift 上可用的存储类型如下表 2-10 所示：

表 2-10 存储类型

存储类型	描述	示例
块存储	1.在操作系统中显示为块设备。 2.适用于可以完全绕过文件系统在底层块读写的应用 3.也称为存储区域网络 (SAN)。 4. 不可共享, 这意味着一次只能有一个客户端可以装载此类型的一个块。	Ceph RBD，OpenStack Cinder， AWS EBS， Azure Disk，GCE persistent disk和 VMware vSphere
文件系统存储	1.在操作系统中显示为文件系统 2.也称为网络连接存储 (NAS)。 3.并发性、延迟、文件锁定机制和其他功能在协议、实现、供应商和扩展之间差别很大。	Linux NFS，NetApp NFS， Azure File，Vendor NFS，AWS EFS
对象存储	1.通过REST API端点访问。 2.应用程序必须将其驱动程序构建到应用程序和容器中。 3.镜像仓库支持使用对象存储。	Ceph Object Storage (RADOS Gateway)，OpenStack Swift，Aliyun OSS，AWS S3，Google Cloud Storage，Azure Blob Storage

上表按目前存在的三种存储类型整理了 OpenShift 支持的存储，主要是帮助读者理清三种存储的区别和分类，可以根据不同的需求选择合适类型的存储。除了公有云存储外，OpenShift 在私有云可以使用的主流的存储包括 NAS、Ceph 以及基于 Linux 实现的 NFS。我们基于不同维度对这几类存储做个对比，如下表 2-11 所示：

表 2-11 OpenShift 常用后端存储对比表

对比项	企业NAS (NFS协议)	OCS	基于Linux的NFS
PaaS平台容器数据持久化的支持	支持	支持	支持
客户端同时读写	支持同时读写	CephFS支持客户端同时读写	支持同时读写
服务端同时读写	支持同时读写	支持同时读写	不支持同时读写，有性能瓶颈
创建与挂载	手动创建，自动挂载	支持自动创建，自动挂载	手动创建，自动挂载
读写性能	高，主要取决于NAS性能	高	一般，主要取决于NFS使用的磁盘性能
服务器投资	相对较高，取决于NAS厂商和类型	一般，使用X86 Server建设集群	低，使用两台X86 Server建设
扩展能力	一般，取决于NAS本身对于可扩展的实现	高，可以动态增加或缩减数据存储池和节点	一般，可以动态增加或缩减数据存储池
安装和管理	安装简单、维护简单	安装简单、维护复杂	安装简单、维护简单
服务端故障恢复	当节点、硬件、磁盘、网络故障时，系统能自动处理，无须管理员介入	当节点、硬件、磁盘、网络故障时，系统能自动处理，无须管理员介入	底层存储的高可用依赖于存储硬件的高可用
客户端故障恢复	OpenShift平台会自动调度到其它可用节点并完成挂载	OCS管理平面通过OpenShift实现高可用，外置Ceph集群的高可用通过自身的架构设计实现。	OpenShift平台会自动调度到其它可用节点并完成挂载

如上表所示，基于 Linux 的 NFS 方案生产不推荐，因为数据高可用难保证，且有性能瓶颈；企业 NAS 看似是最好的选择，但是也存在成本较高，扩展难等问题。而 OCS 由于与 OpenShift 完美集成，并且支持外置 Ceph 的模式，因此会越来越成为 OpenShift 持久化存储的理想选择。

2

OpenShift 存储容量规划

OpenShift 存储容量规划包括 OpenShift 节点、OpenShift 附加组件、OpenShift 上运行的应用，由于 OpenShift 上运行的应用没有通用的存储容量规划方法，需要根据具体的业务需求规划，这里我们就不再讨论。下面我们将分别说明 OpenShift 节点和 OpenShift 附加组件这两部分的存储容量进行规划。

OpenShift 节点所需要的存储主要是节点文件系统上一些特殊的目录，通常消费本地存储。

2.1

Etcd 数据存储

Etcd 用于保存 OpenShift 所有的元数据和资源对象，官方建议将 Master 和 Etcd 部署在相同的节点，也就是 Etcd 数据保存在 Master 节点的本地磁盘，默认在/var/lib/etcd/目录下，该目录最小需要 20 GB 大小的存储。

2.2

Docker/CRI-O 本地存储

Docker/CRI-O 作为容器运行时，在每个节点都会运行，在运行过程中会保存镜像到本地以及为容器运行分配根空间都需要消耗本地磁盘，官方建议在生产环境中专门为运行时配置一块裸磁盘。这部分存储的大小取决于容器工作负载、容器的数量、正在运行的容器的大小以及容器的存储要求，通常建议配置 100G 甚至更大。另外，建议最好定期清理本地无用的镜像和容器，一方面是为了释放磁盘空间，一方面是为了提升运行时性能。

2.3

OpenShift 节点本地日志存储

OpenShift 节点运行的进程的日志默认存放在/var/log 目录下，该目录最小需要 15G。

除了这三个对于 OpenShift 相对关键的目录之外，其余操作系统分区规划遵循企业操作系统安装规范即可。在清楚了 OpenShift 节点存储规划之后，下面我们看看 OpenShift 附加组件的存储规划。OpenShift 包含一些附件组件是需要挂载持久存储的，如镜像仓库、日志存储等，这部分存储是挂载到容器中消费，通常使用的是非本地存储。主要包含如下几部分：

镜像仓库

镜像仓库可以选择的存储类型有块存储、文件系统存储、对象存储，我们推荐优先使用对象存储，其次是文件系统存储，最后才是块存储。如果选择块存储就只能一个实例读写，不利于镜像仓库高可用的实现。

OpenShift 中的镜像仓库包括 OpenShift 内部镜像仓库和外部镜像仓库。内部镜像主要用于存放在开发过程中生成的应用镜像，存储空间增长主要取决于构建生成应用的二进制文件的数量和大小；OpenShift 外部镜像仓库在开发测试环境用于存储应用所需要的基础镜像，如 Tomcat 镜像，存储空间主要取决于保存的基础镜像的数量和大小，对于一个企业来说，基础镜像相对是固定的，存储空间增长不会很大；在生产环境的镜像仓库存放用于发布生产的镜像，存储空间取决于保存应用镜像大小和数量。

经过上述描述，可以发现，开发测试环境的内部镜像仓库的存储空间增长是最快的，因为频繁的构建，每天会产生大量的镜像上传到内部镜像仓库。我们可以根据每天构建应用的次数以及每次构建生成应用二进制的大小粗略估计出该仓库所需要的存储空间，计算公式如下：

内部镜像仓库存储空间=平均每天构建应用的次数 平均应用二进制的平均大小 保留镜像的天数 + 基础镜像总大小

其中，基础镜像总大小可以在开发测试环境的外部镜像仓库拿到这个数据，当然也可以给一个适当足够大的值。

开发测试环境的外部仓库存放基础镜像，相对固定，每个企业对该仓库存储空间的需求是不一样的，按以往经验来说，通常配置 100G 或 200G 是足够的。

生产环境的镜像仓库可以通过平均每天发布应用的次数、平均镜像大小以及保留的天数，计算公式：

生产镜像仓库存储空间=平均每天发布应用的次数 平均镜像大小 保留的天数

到此为止，所有的镜像仓库存储容量就规划完了，如果在使用过程中出现了存储不足的情况，优先考虑清理无用镜像释放空间，如果确实无法释放，再考虑扩容空间。

日志系统

日志系统默认使用容器化的 EFK 套件，唯一需要挂载存储的是 ElasticSearch，可以选择的存储类型有块存储和文件系统存储。出于性能上的考虑，推荐优先使用块存储，其次选择文件系统存储。如果使用文件系统存储，则必须每个 ElasticSearch 实例分配一个卷。

ElasticSearch 存储大小可以使用以下方法进行粗略估算：

统计应用输出日志每行的平均字节数，如每行 256 bytes；统计每秒输出的行数，如每秒输出 10 行。那么一天一个 Pod 输出的日志量为：

256 bytes 10 60 60 24 大约为 216MB

在根据运行的 Pod 数目计算出每天大约需要的日志存储量，再根据需要保留的日志的天数计算出总日志存储空间需求，建议多附加 20%的额外存储量。

如在生产环境 200 个容器，24 小时积累日志 43G 左右。如果保留一周，则需要 300G 的存储空间。

上述计算只是估算了保存一份日志的存储空间，我们都知道 ElasticSearch 是通过副本机制实现数据的高可用的，这样为高可用 ElasticSearch 规划空间时还需要考虑副本数的影响，通常是根据一份日志的存储空间直接乘以保留的副本数。

以上方法只是一个粗略估计，如果需要更为精确的估算，则最好在应用稳定上线之后，通过 ElasticSearch 每天增加的存储空间推算每天的日志增长量。

OpenShift 监控系统

OpenShift 的监控系统使用 Prometheus 套件，需要挂载存储的组件有 Prometheus、AlertManager。可以使用存储类型都是块存储和文件系统存储，推荐优先使用块存储，其次使用文件系统存储。如果使用文件系统存储最好经过测试后再使用。

OpenShift 中的 Prometheus 默认使用 Operator 部署，配置存储需要配置动态存储类或提前创建好可用的 PV。Prometheus 有两个实例，AlerManager 有三个实例，总共需要 5 个 PV。

AlertManager 所需要的存储空间较小，按经验配置 40G 是足够的。Prometheus 所需要的存储与集群节点数、集群 Pod 数、保留数据天数（默认 15 天）等因素有关。官方在默认配置下，给出四组 Prometheus 测试数据供我们参考，如下表 2-12 所示：

表 2-12 Prometheus 存储需求测试数据

节点数	Pod总数	Prometheus每天增长的存储	Prometheus每15天增长的存储
50	1800	6.3GB	94GB
100	3600	13GB	195GB
150	5400	19GB	283GB
200	7200	25GB	375GB

根据上述测试数据，在默认配置下，Prometheus 在 15 天需要的存储量基本与节点数和 Pod 数呈线性增长，我们根据这个比例估算我们需要的存储量即可，同样建议在计算时多附加了 20%的额外存储量预防意外情况。

3

本文选自《OpenShift 在企业中的实践》（第 2 版），经出版社授权发布。

推荐语：经典畅销书再次升级！红帽首席解决方案架构师联合撰写，20 位全球知名企业 IT 负责人推荐，基于 OpenShift v4，详述 PaaS、DevOps、云原生、微服务治理。完整描绘企业数字化转型路线，为企业通过 OpenShift 实现 IT 转型给出具体建议和参考架构。

---

推荐阅读